Date: Wed, 4 May 94 04:30:14 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #137 

To: Ham-Digital 


Ham-Digital Digest Wed, 4 May 94 Volume 94 : Issue 137 


Today's Topics: 
Idea, 10-10 members.... 
Integrate HF w/WAN 
NET/ROM NRS specification 
New FCC rules on forwarding 
PacketRadio forLinux with Baycom ?? (2 msgs) 
Packet radio FTP sites 
still looking for project ideas (2 msgs) 
unsubscribe 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 3 May 1994 19:10:20 GMT 

From: darwin.sura.net!rsg1.er.usgs.gov!news.cs.indiana.edu!noose.ecn.purdue.edu! 
constellation.ecn.purdue.edu! wb9omc@seismo.css. gov 

Subject: Idea, 10-10 members.... 

To: ham-digital@ucsd.edu 


I'd like to gauge the interest among members of 10-10 International who 
are on the Internet for a group, possibly called: 


rec.radio.amateur.1010 
The purpose of the group would be multiple: 


1) to help disseminate information of general interest to 10-10 members 
who have access to Internet. 


2) to help 10-10 members set up skeds, nets and other communications events. 


3) to help develop interest in not only 10-10 International but to maintain 
interest in 10 meters in xspitex of the current lull in the band. 


4) to help develop computer operating aids for 10-10 contests and 
paperchasing. 


5) to serve as one focal point for 10-10 members to discuss the organization, 
contest rules, awards rules, etc. 


6) other future purposes realted to Amateur Radio and 10-10. 


KKKKKKKKKKK 


I think that emailing me would probably be preferred to clogging up 
a number of newsgroups with "me too!" kinds of mail. 


If you are interested or have a xbrief*x thought on the subject, please 
email: 


wb9omc@harbor.ecn.purdue. edu 
flames and/or mail bombs will be ignored, deleted, /dev/null'ed, etc. :-) 


If interest seems positive enough, I will make some contacts with the 
officers of 10-10 to find out in what ways, if at all, they would 
like to make contact and maintain contact with such a newsgroup. 


73 


Duane, WB9IOMC 


Date: Tue, 3 May 1994 13:37:51 GMT 

From: ihnp4.ucsd.edu!sdd.hp.com!nigel.msen.com!zib-berlin.de!math.fu-berlin.de! 
news@network.ucsd.edu 

Subject: Integrate HF w/WAN 

To: ham-digital@ucsd.edu 


In article <7c5PLc6w165w@voxbox.norden1.com>, jgrubs@voxbox.norden1l.com (Jim 
Grubs, W8GRT) says: 

> 

>Correct me if I'm wrong, but isn't HF illegal under ITU 

>Conventions for intranational land mobile use? 


Don't know, is it? This could be a problem! I'll talk with our frequency 
coordinator and see what he can tell me. Would it be in an FCC reg, the 
Communications Acts of 19xx, or some other reference? 


Kevin der Kinderen mtimpn@baileys-emh2.army.mil 703-756-1971 
Opinions voiced are my own, not my employer's. 


Date: Tue, 3 May 1994 08:37:18 +0000 

From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!pipex!demon! 
athnet.ath.forthnet.gr!svixv@network.ucsd.edu 

Subject: NET/ROM NRS specification 

To: ham-digital@ucsd.edu 


I need the specification of NRS (Net/Rom transmission over serial 
lines). Is it available anywhere? 


Thanks, 

Costas 
+--------------------------------------------------------------- + 
| Costas Krallis - SV1XV - Athens Greece (LOC: KM18UA) | 
| Packet Radio: svixv@sviuy.ath.grc.eu 
| Internet: svixv@athnet.ath.forthnet. gr 
| S-Mail: P.0.Box 3066, GR-10210 Athens, GREECE | 
| PGP Public Key 0x9E2905 available from all public keyservers. | 
+--------------------------------------------------------------- + 


Date: 3 May 94 15:37:28 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: New FCC rules on forwarding 
To: ham-digital@ucsd.edu 


The FCC has finally released the text of the Part 97 changes relative 
to message forwarding. According to an article in the April 26 ARRL Letter, the 
new rules are: 


97.3 Definitions. 


(7) Auxiliary stations. An amateur station, other than ina 
message forwarding system, that is transmitting communications 


point-to-point within a system of cooperating amateur stations. 


(28) Message forwarding system. A group of amateur stations 
participating in a voluntary, cooperative, interactive arrangement 
where communications are sent from the control operator of an 
originating station to the control operator of one or more 
destination stations by one or more forwarding stations. 


(36) Repeater. An amateur station that simultaneously 
retransmits the transmission of another amateur station ona 
different channel or channels. 


97.109 Station control. 


(e) No station may be automatically controlled while 
transmitting third party communications, except a station 
participating as a forwarding station in a message forwarding 
system. 


97.205 Repeater station. 


(g) The control operator of a repeater that retransmits 
inadvertently communications that violate the rules in this Part 
is not accountable for the violative communications. 


97.219 Message forwarding system. 
[Section 97.216 is redesignated Section 97.217] 


(a) Any amateur station may participate in a message 
forwarding system, subject to the privileges of the class of 
operator license held. 


(b) For stations participating in a message forwarding sytem, 
the control operator of the station originating a message is 
primarily accountable for any violation of the rules in this Part 
contained in the message. 


(c) Except as noted in paragraph (d) of this section, for 
stations participating in a message forwarding system, the control 
operators of forwarding stations that retransmit inadvertently 
communications that violate the rules in this Part are not 
accountable for the violative communications. They are, however, 
responsible for discontinuing such communications once they become 
aware of their presence. 


(d) For stations participating in a mesage forwarding system, 
the control operator of the first forwarding station must: 

(1) Authenticate the identity of the station from which it 
accepts communications on behalf of the system: or 

(2) Accept accountablility for any violation of the rules in 
this Part contained in messages it retransmits to the system. 


These rules will take effect June 1, 1994. 


Bob Nielsen, W6SWE Internet: w6swe@tapr.org 
Tucson, AZ AMPRnet: w6swe@w6swe.ampr.org 
[44.124.12.16] AX.25: w6swe@wb7tls.az.usa.na 


Date: 3 May 1994 21:04:34 GMT 

From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net! torn! 
hermes.acs.ryerson.ca!ee.ryerson.ca! jeff@network.ucsd.edu 

Subject: PacketRadio forLinux with Baycom ?? 

To: ham-digital@ucsd.edu 


irene burlingame (ipb@unlinfo.unl.edu) wrote: 
: Is there anybody out there hwo has experience with setting up a Linux 
Packetradio server using a Bycom modem? i need info desperately! 


Unfortunately, Linux will never be able to support Baycomm. The Baycomm 
modem requires that the processor be 100% devoted to the modem while 
packets are coming in and out, and that's just not possible under 

a multitasking OS. Even if you could do it, it's really not desireable, 
it would bring the whole machine to a halt! 


73 de Jeff / VE3DIF 
Jeff@EE.Ryerson.Ca 
VE3DJF@bbs.VE3RPI.ampr.org 


Date: 4 May 94 10:01:55 GMT 

From: agate! howland.reston.ans.net!EU.net!CERN.ch!dxcern! 
jalocha@ucbvax.berkeley.edu 

Subject: PacketRadio forLinux with Baycom ?? 

To: ham-digital@ucsd.edu 


In <2q6e92$kbk@hermes.acs.ryerson.ca> jeff@ee.ryerson.ca (Donald Jef£ Dionne) 
writes: 


>Unfortunately, Linux will never be able to support Baycomm. The Baycomm 
>modem requires that the processor be 100% devoted to the modem while 
>packets are coming in and out, and that's just not possible under 

>a multitasking OS. Even if you could do it, it's really not desireable, 
>it would bring the whole machine to a halt! 


Not 100% true :-) For receiving packets the processor only reacts 

to modem output transitions and it is done via an interrupt. 

The key point is that the CPU has to measure the time when the interrupt 
occured with a precision better than the time taken by a single bit 

(3.3 ms for 300 bps, 0.833 ms for 1200 bps). A precision of about 

Q@.1 ms is good enough for 1200 bps. 

The trouble comes if the processor runs with interrupts disabled 

for the time which is longer than the precision needed... 

I can not say whether the LINUX system does so. 


The approach I described above is applied in the BAYCOM program 
and the AX.25 driver for the NOS written by me. The TFPCX driver 
takes a different approach by speeding up the system timer 

and sampling the modem's output at three times the bit rate 
frequency. 


Bottom line: if the LINUX operating system doesn't "blind" the CPU 
to interrupts for longer than about 0.1 ms one could (in principle) 
write a driver for the BAYCOM modem running at 1200 bps. 


Pawel, SP9VRC 


Date: Tue, 03 May 94 18:14:52 GMT 

From: koriel!cs.utexas.edu!howland.reston.ans.net!EU.net!uknet!ukc! 
raven.ukc.ac.uk!mrb3@ames.arpa 

Subject: Packet radio FTP sites 

To: ham-digital@ucsd.edu 


HI all, 


I was wondering if anyone has a list of the best ftp sites around 
that contain amateur radio / packet related programs. 


Many thanks 


Matthew 


Packet G7KSG@GB7ZAA 


Date: 3 May 94 23:39:56 GMT 

From: dog.ee.lbl.gov!ihnp4.ucsd.edu!sdd.hp.com!saimiri.primate.wisc.edu! 
news.doit.wisc.edu!kolstad@ucbvax.berkeley.edu 

Subject: still looking for project ideas 

To: ham-digital@ucsd.edu 


In article <1994May3.152521.1@exodus.valpo.edu> acc_mwb@exodus.valpo.edu (Mike 
Barton) writes: 

> 

>We'd like it to be in the are of electronics. Audio applications, signal 
>processing, waveform modification, signal generation, filtering, etc. I don't 
>know what else... so many different things, we hardly know where to start. 


I'd be impressed if you got a 1Gb/s fiber optic link going. :-) 


I take an opto-electronics course once that had a student made fiber optics 
demonstrator box that cranked out a whole 100 kbps!! Oooh, wow! 


(Sorry... most of the labs here at the U of W have really crappy 
equipment... there's a reason they call this a "Research University.") 


---Joel Kolstad 


Date: 3 May 94 15:24:07 CDT 

From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!math.ohio-state.edu! 
sol.ctr.columbia.edu!usenet.ucs.indiana.edu! vunews.valpo.edu!exodus.valpo.edu! 
acc_mwb@network.ucsd.edu 

Subject: still looking for project ideas 

To: ham-digital@ucsd.edu 


I am currently finishing my junior year in electrical engineering. Next year, 
I will be working on a "Senior project" with at least one other student. 
Taking a look ahead, we're trying to figure out some options for projects that 
we could do. 


We'd like it to be in the are of electronics. Audio applications, signal 


processing, waveform modification, signal generation, filtering, etc. I don't 
know what else... so many different things, we hardly know where to start. 


Other options that we'd like to consider are those in the communication 

electronics area. We'll be having communic. theory and electronics classes 
next year, so right now, we don't have much to go on in that area. I am an 
amateur radio operator. Something dealing with that would be really great! 


Other areas of interest that might generate a good project would me some 
digital / electronics combination, applications dealing w/ transistors as 
switching (not in a power situation, but rather small things). 


This project lasts two semesters. In the fall we finalize our project. Write 
up some designs, present the project, make a "project request" or something 
like that. Then, by Dec., have it ready to put together. Starting in Jan., we 
build a prototype, fix it, get it to work (ie. re-design and re-design and..). 
Finally, we'll end the semester by writing final reports, documentation and 
doing more presentations. 


We'd like any ideas for projects that you think would be interesting, 
obtainable, and fit the idea of this "senior project." 


___PLEASE____ if you've got any ideas, send some email to me. Just give us a 
couple of ideas that you might have. I'll post a summery to the list if I get 
some responses. 


Date: 3 May 94 22:55:17 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: unsubscribe 

To: ham-digital@ucsd.edu 


unsubscribe 
help 


Date: Tue, 3 May 1994 12:41:27 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov! agate! library.ucla.edu!csulb.edu!csus.edu! 
netcom.com! rogjd@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <1994Apr26.000004.23739@news.csuohio.edu>, 
<1994Apr26.151137 .6512@midway.uchicago.edu>, <gregCoxFjJ5.9yu@netcom.com>y 
Subject : Re: A soft spot in the Pactor protocol??? 


Anyone know if GTOR has a reconnect protocol? Or is it similar to Pactor 
in this regards? 


rogjd@netcom.com 
Glendale, CA 
AB6WR 


End of Ham-Digital Digest V94 4137 
KKKKKKKKKKKKKKKKKKKKKKEKKERA KKK 


